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FOREWORD 


APJ,  under  contract  to  HQs,  AMCCOM,  has  initiated  the 
automation  of  the  LSA  Tasks  (MIL-STD-1388-1) ,  and  the  assessment  of 
the  ILS  elements  (AR  700-127) .  A  major  goal  is  to  unify  military 
and  contractor  approach  to  the  performance  of  ILS  and  LSA. 

Detailed  to  meet  all  requirements  of  ILS  and  LSA,  the  automated 
process  will  continue  to  provide  the  flexibility  in  selecting  tasks 
and  elements  to  be  addressed  at  each  life  cycle  stage.  A  major 
advantage  of  this  approach  is  to  insure  that  the  application  of  each 
task  is  consistent  with  prescribed  Army  policies  and  procedures . 

This  report  consolidates  the  Structured  Analysis  and  Structured 
Design  under  one  cover  for  the  respective  LSA  Tasks.  Structured 
Analysis  provides  a  logical  model  of  the  method  to  perform  an  LSA 
Task.  This  logical  model  facilitates  the  development  of  a 
Structured  Design  that  provides  the  detailed  procedures  to  perform 
the  analysis.  Both  the  logical  model  and  detailed  procedures  are 
used  to  develop  the  application  software  programs  which  will  be 
provided  to  Government  and  contractor  personnel  to  assist  in  the 
performance  of  the  LSA  Task. 

Included  in  this  report  are  the  Data  Flow  Diagrams  (DFDs )  for 
LSA  Subtask  301.2.5,  "Functional  Requirement  Risk  Analysis"  and  the 
corresponding  descriptions  of  the  processes,  data  flows,  data 
stores,  and  external  entities  identified  on  each  DFD  (Annex  B) .  In 
addition,  the  DFDs  are  further  developed  into  step-by-step 
procedures  (Annex  C)  which  identifies  how  to  use  the  data  to  carry 
out  the  processes  which  ultimately  lead  to  accomplishing  the  LSA 
Subtask . 

To  assist  managers  in  planning  and  controlling  this  task. 
Venture  Evaluation  Review  Technique  (VERT)  Batch  Input  files  are 
provided  (Annex  D) .  These  VERT  tools  provide  government  agencies 
with  complete  packages  to  give  contractors  that  cover  both  technical 
and  managerial  aspects  of  a  task.  This  approach  establishes  a 
standardized  form  of  communication  and  management  between 
contractors  performing  the  task  and  government  personnel  reviewing 
the  task. 

To  view  this  work  in  context.  Annex  E  of  this  report  also 
presents  a  brief  overview  of  Structured  Analysis  and  its  place  in 
the  overall  systems  development  process .  The  overview  and  certain 
portions  of  the  introductory  text  are  repeated  verbatim  in  every 
report  in  this  series  so  that  each  report  is  free  standing. 
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INTRODUCTION 


PURPOSE 

The  purpose  of  this  report  series  is  to  present  the  results  of 
the  APJ  efforts  under  Contract  DAAA21-86-D-0025  for  coordination  with 
the  AMCCOM  Program  Manager  prior  to  in-depth  programming  of  ILS  and  LSA 
functions  and  processes.  LSA  Task  301,  "Functional  Requirements  Risk 
Identification"  (LSA  Subtask  301.2.3  "Functional  Requirement  Risk 
Analysis")  is  addressed  in  this  report. 

BACKGROUND 

The  Department  of  the  Army  has  a  requirement  for  management 
control  over  contractor  and  Government  agency  response  to  the 
requirements  of  AR  700-127,  "Integrated  Logistic  Support",  and  MIL- 
3TD-1388-1,  "Logistic  Support  Analysis".  HQs  AMCCOM  has  initiated 
action  to  structure  each  of  the  LSA  tasks,  the  assessment  of  each  ILS 
element,  the  form  of  the  results,  and  the  detailed  processes  to  insure 
consistency  with  currant  Army  policies,  procedures,  and  techniques. 

This  approach  (undertaken  by  AMCCOM  and  APJ)  will  insure 
uniformity  in  efforts  and  products,  reproducibility  of  analyses,  and 
a  well-defined  structure  which  can  be  coordinated  among  all 
participants  in  the  logistic  process  to  arrive  at  common  understanding 
and  procedures . 

SCOPE 


This  report  summarizes  the  results  of  the  Structured  Analysis  of 
LSA  Task  301,  "Functional  Requirements  Identification",  LSA  Subtask 
301.2.3,  "Functional  Requirements  Risk  Identification",  and  presents 
the  associated  Data  Flow  Diagrams  (DFDs)  developed  from  the  Structured 
Analysis.  The  portions  of  the  Data  Dictionary  relating  to  labels, 
names,  descriptions,  processes,  data  flows,  data  stores,  and  external 
entities  are  included  in  their  present  degree  of  completeness.  (The 
Data  Dictionary  is  a  "living  document"  that  evolves  through  the 
analysis  and  design  process) . 

The  Data  Dictionaries  developed  for  each  of  the  individual  LSA 
Subtasks  are  integrated  together  into  a  Master  Data  Dictionary. 
Integration  of  the  individual  Data  Dictionary  involves  the  combination 
of  simular  Data  Flows,  Data  Stores,  and  External  Entities.  The 
resulting  Master  Data  Dictionary  may  well  contain  some  minor 
differences  from  the  definitions  that  appear  in  this  report.  All 
processes,  and  of  course,  the  content  of  the  structured  design  will 
remain  identical. 
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The  Structured  Design  portion  of  this  report  develops  the 
processes  and  data  flows  developed  in  the  DFDs  into  procedures  which 
are  used  to  accomplish  the  LSA  Tasks .  The  DFDs  provide  the  method  and 
the  Design  implements  it,  by  formulating  a  guide  for  programmers  to 
write  software  applications . 

This  report  presents  a  brief  overview  of  Structured  Analysis  and 
its  place  in  the  overall  systems  design  process  to  assist  the  reader 
who  may  not  be  fully  briefed  on  the  symbols  and  conventions  used.  It 
is  supported  by  Annex  E,  which  defines  each  element  in  Structured 
Analysis,  and  by  a  separate  Glossary. 


LSA  SUBTASK  301.2.3  DESCRIPTION 

Subsequent  to  the  identification  and  documentation  of  operational 
and  support  functions,  as  accomplished  in  LSA  Subtask  301.2.1,  and  the 
identification  of  unique  functional  requirements  and  supportability, 
cost  and  readiness  drivers,  as  accomplished  in  LSA  Subtask  301.2.2, 
functional  requirements  risk  identification  is  performed.  This  process 
is  used  to  develop  areas  of  potential  risk  associated  with  each  of  the 
functions  previously  identified. 

LSA  Subtask  301.2.3  is  designed  to  alert  program  managers  and 
analysts  so  that  special  emphasis  is  required  concerning  these  risk 
areas . 

Risks  identified  in  earlier  LSA  Subtask  actions  (LSA  tasks  202, 
203,  204,  205)  have  the  potential  for  impact  upon  LSA  Subtask  301.2.3, 
therefore,  a  detailed  assessment  of  this  potential  is  made.  Adverse 
(risk)  impacts  are  documented. 

Since  the  greatest  potential  for  functional  requirements  risk  is 
generated  by  new  design  technology  and/or  operational  concepts,  special 
emphasis  is  placed  on  LSA  Subtask  301.2.2  functions/drivers  as 
possessing  the  greatest  potential  for  functional  risk. 

Annotations  of  risk  relationships  and  rationale  for  risk 
classification  is  made  in  this  subtask  to  assure  an  audit  trail  for 
follow  on  analyses .  The  results  of  this  subtask  will  be  utilized  in 
subsequent  LSA  Tasks  efforts  to  insure  full  consideration  of  functional 
potential  risks  associated  with  system  development. 


APPROACH 

The  APJ  approach  to  Structured  Analysis  of  the  LSA  task  is: 

1.  Scope  the  process  defined  in  MIL-3TD-1388-1A  in  the  context 
of  the  other  LSA  tasks  . 
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2.  Review  the  guidance  provided  in  AMC  PAM  700-11,  "Logistics 
Support  Analysis  Review  Team  Guide" . 

3.  Review  the  applicable  Data  Item  Descriptions  (DIDs)  from 
the  Acquisition  Management  Systems  and  Data  Requirements  Control  List 
(AMSDL)  published  by  the  Department  of  Defense. 

4 .  Review  all  source  documents  referenced  in  the  AMSDL  as 
applicable  to  the  referenced  DIDs  of  interest. 


STRUCTURED  ANALYSIS  FOR  LSA  SUBTASK  301.2.3  -  FUNCTIONAL  REQUIREMENTS 
RISK  ANALYSIS 

The  Data  Flow  Diagram  is  a  tool  that  shows  the  flow  of  data, 
(i.e.,  data  flows  from  sources)  and  is  processed  by  activities  to 
produce  intermediate  or  final  products. 

The  DFD  provides  a  useful  and  meaningful  partitioning  of  a  system 
from  the  viewpoint  of  identification  and  separation  of  all  functions, 
actions,  or  processes  so  that  each  can  be  introduced,  changed,  added, 
or  deleted  with  minimal  disruption  of  the  overall  program,  i.e.,  it 
emphasizes  the  underlying  concept  of  modularity  and  identifiable 
transformations  of  data  into  actionable  products. 

A  series  of  three  (3)  DFDs  have  been  developed  to  structure  the 
LSA  subtask  relative  to  operations  and  other  support  functions: 

1.  301.2.3  Functional  Requirements  Risk  Identification 

2.  301.2.3.3A  Functional  Requirements /BCS  Review 

3.  301.2.3.7A  Functions/Requirements  Risk  Validation 

Each  DFD  is  keyed  to  the  specific  task  (LSA,  in  this  case) 
through  the  identification  number  assigned  in  the  lower  right  hand 
box.  The  Alpha  codes  indicate  the  level  of  indenture  or  explosion 
below  the  top  level,  i.e.,: 

Top  level . LSA  DFD  301.2.3 

First  Indenture . LSA  DFD  301.2.3.3A 

Each  DFD  makes  reference  to  the  basic  LSA  task  it  addresses,  as 
well  as  the  level  of  indenture  (explosion)  of  the  DFD.  For  example, 
the  first  or  top  level  DFD,  301.2.3  refers  to  the  paragraph  in  MIL- 
STD-L388-1A  which  describes  the  task.  One  of  the  processes  (bubbles) 
on  the  top  level  diagram  (301.2.3.3)  is  expanded  and  identified  as 
"301 . 2 . 3 . 3A" ,  a  second  level  of  301.2.3.3"  (Alpha  "A"  indicates  second 
level)  . 
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Four  standard  symbols  are  used  in  the  drawing  of  a  DFD  (see 
Annex  E,  Figure  2)  . 

A  copy  of  each  DFD  is  presented  in  Annex  B,  accompanied  by  the 
Data  Dictionary  process  elements.  Each  entry  made  in  the  DFDs  has  a 
corresponding  entry  in  the  Data  Dictionary,  immediately  following  each 
of  the  DFDs . 


VERT  DIAGRAMS 

The  Venture  Evaluation  Review  Technique  (VERT)  was  developed  as 
a  network  analysis  technique  to  facilitate  management  decision  making. 
It  allows  systematic  planning  and  control  of  programs  and  enables 
managers  to  find  solutions  to  real  life  managerial  problems.  The  VERT 
Diagrams  and  Input  Files  for  this  task  can  be  found  in  Annex  D.  In 
order  to  understand  how  these  Input  Files  were  developed,  a  brief 
discussion  of  the  methodology  used  is  provided.  The  same  explanation 
is  repeated  verbatim  in  every  report. 
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ANNEX  A 

LSA  TASK  301 

FUNCTIONAL  REQUIREMENTS  IDENTIFICATION 


ANNEX  A 


LSA  TASK  301 

FUNCTIONAL  REQUIREMENTS  IDENTIFICATION* 


301.1  PURPOSE .  To  identify  the  operations  and  support  functions  that 
must  be  performed  for  each  system/equipment  alternative  under 
consideration  and  then  identify  the  tasks  that  must  be  performed  in 
order  to  operate  and  maintain  the  new  system/equipment  in  its  intended 
environment . 


301.2  TASK  DESCRIPTION 

301.2.3  Identify  any  risks  involved  in  satisfying  the  functional 
requirements  of  the  new  system/ equipment . 


A- 1 


Abstracted  verbatim  from  MK-STD-1388-1A,  11  April  1983 


page  31 . 
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SUBTASK  301.2.3 

FUNCTIONAL  REQUIREMENTS  RISK  ANALYSIS 
DATA  FLOW  DIAGRAMS  AND  DATA  DICTIONARY 
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DATE:  5-JAN-90 
TIME:  12:30 


APJ  966-242 
PROCESSES 


PAGE  1 
EXCELERATOR  1.84 


Haas  Labsl  Description 


301.2.3.1  REVIEW  PURPOSE: 

FUNCTIONAL  THE  OBJECTIVE  OF  THIS  PROCESS  IS  TO  REVIEW  THE  RESULTS 

REQ  5  SUPP  OF  LSA  SUBTASKS  301.2.1  AND  301.2.2  WHICH,  TOGETHER  IDENTIFIED  AND 
DRIVERS  DOCUMENTED  THE  FUNCTIONAL  REQUIREMENTS,  UNIQUE  TO  THE  SYSTEM/ EQUIPMENT 
RESULTING  FROM  NEW  DESIGN  TECHNOLOGY,  OPERATIONAL  CONCEPTS, 
SUPPORIABILITY,  COST  AND  READINESS  DRIVERS. 

PROCEDURES:  1.  OBTAIN  RESULTS  OF  SUBTASK  301.2.1  AND  301.2.2. 

2.  MATCH,  AND  RECORD  THE  FUNCTIONAL  REQUIREMENTS  FOR  EACH 
ALTERNATIVE  SYSTEM  WITH  THE  SUPPORIABILITY,  COST  AND 
READINESS  DRIVERS,  AND  UNIQUE  SYSTEM/ EQUIPMENT 
FUNCTIONAL  REQUIREMENTS. 

301.2.3.2  FUNCTIONAL  PURPOSE: 

BCS  REVIEW 

TO  EVALUATE  FUNCTIONAL  REQUIREMENTS,  UNIQUE  FUNCTIONAL  REQUIREMENTS 
AND  SUPPORIABILITY,  COST  AND  READINESS  DRIVERS  PREVIOUSLY  IDENTIFIED 
AGAINST  THE  BASELINE  COMPARISON  SYSTEM  DEVELOPED  IN  LSA  TASK  203  TO 
PROVIDE  HISTORICAL  DATA  UPON  WHICH  TO  BASE  RISK  DETERMINATIONS. 


301.2.3.2A1  FUNCTIONAL  PURPOSE: 

RQMNT  BCS  DETERMINE  THROUGH  REVIEW  OF  LSA  SUBTASK  203.2.2,  THE 

REVIEW  RELATIONSHIPS  THAT  MAY  EXIST,  BETWEEN  THE  BASELINE  COMPARATIVE  SYSTEM 
AND  THE  FUNCTIONAL  REQUIREMENTS  AND  DRIVERS  PREVIOUSLY  IDENTIFIED. 

301.2.3.2A2  FUNCTIONAL  PURPOSE: 

RQMNTS 

QUAL  SUPP  REVIEW  THE  QUALITATIVE  SUPPORTABILITY  PROBLEMS  IDENTIFIED  IN 

REVIEW  LSA  SUBTASK  203.2.4  AGAINST  FUNCTIONAL  REQUIREMENTS,  UNIQUE  FUNCTIONS 
AND  SUPPORTABILITY,  COST  AND  READINESS  DRIVERS  TO  IDENTIFY  HISTORICALLY 
SIGNIFICANT  IMPACTS  UPON  THE  NEW  SYSTEM/EQUIPMENT. 


301.2.3.2A3  FUNCTIONAL  PURPOSE: 

RQMNTS  BCS 

DRIVER  THE  OBJECTIVE  OF  THIS  PROCESS  IS  TO  COMPARE  THE  FUNCTIONAL 

REVIEW  REQUIREMENTS  FOR  THE  NEW  SYSTIM/EQUIPMENT  WITH  THE  HISTORICAL 
SUPPORTABILITY,  COST  AND  READINESS  DRIVER  DATA  CONTAINED  IN  LSA 
SUBTASKS  203.2.5  AND  203.2.6  AND  DETERMINE  POTENTIAL  PROGRAM  RISKS. 


30 1 . 2 . 3 . 2A4  FUNCTIONAL  PURPOSE : 

RQMNTS  RSK  THE  OBJECTIVE  OF  THIS  PROCESS  IS  TO  DETERMINE  IF  THE  RISKS 

4  ASSUMP  AND  ASSUMPTIONS  ASSOCIATED  WITH  THE  USE  OF  COMPARAITVE  SYSTEMS  (LSA 

REVIEW  SUBTASK  203.2.8)  INFLUENCE  THE  FUNCTIONAL  REQUIREMENTS,  UNIQUE 

REQUIREMENTS  AND  SUPORIABILITY,  COST  AND  READINESS  DRIVERS  FOR  NEW 
SYST24/ EQUIPMENT . 

PURPOSE: 

THIS  PROCESS  ASSESSSES  THE  RESULTS  OF  THE  PRECEEDING 
REVIEWS  OF  FUNCTIONAL  REQUIREMENTS,  UNIQUE  REQUIRBffiNTS  AND 
SUPPORIABILITY,  COST  AND  READINESS  DRIVER  REVIEW  WITH  THE  3ASELINE 
COMPARISON.  AS  A  RESULT,  POTENTIAL  FUNCTIONAL  RISKS  ARE  IDENTIFIED. 


301.2.3. 2A5  FUNCTIONAL 
RQMNTS  BCS 
VALIDATION 
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301.2.3.3  FUNCTIONAL  PURPOSE: 

REQ  CONST 

RISK  THE  OBJECTIVE  OF  THIS  PROCESS  IS  TO  ASSESS  RELATIONSHIPS 

ASSESSMENT  BETWEEN  THE  FUNCTIONAL  REQUIRMWTS  AND  SUPPORTABILITY,  COST  AND 

READINESS  DRIVERS  AND  RISKS  ASSOCIATED  WITH  SUPPORTABILITY  CONSTRAINTS. 

301.2.3.4  FUNCTIONAL  PURPOSE: 

REQ  DESIGN  THE  PURPOSE  OF  THIS  PROCESS  IS  TO  DETERMINE  THE 

RISK  ASSES  RELATIONSHIPS  THAT  EXIST  BETWEEN  THE  RISKS  ASSOCIATE)  WITH  DESIGN 
OBJECTIVES,  AS  IDENTIFIED  IN  LSA  SUBTASK204,  AND  FUNCTIONAL 
REQUIREMENTS  AND  SUPPORTABILITY,  COST  AND  READINESS  DRIVERS. 

301.2.3.5  FUNCTIONAL  PURPOSE: 

REQ  SUPP  THE  OBJECTIVE  OF  THIS  PROCESS  IS  TO  ASSSS  THE 

RISK  ASSES  RELATIONSHIP  OF  SUPPORTABILITY  RISKS  ASSOCIATED  WITH  NEW  TECHNOLOGY  AND 
SUPPORTABILITY,  COST  AND  READINESS  OBJECTIVES  RISK  AS  IDENTIFIED  IN  LSA 
SUBTASK  205.2.2,  AND  FUNCTIONAL  REQUIREMENTS,  UNIQUE  FUNCTIONAL 
REQUIREMENTS  AND  SUPPORTABILITY,  COST  AND  READINESS  DRIVERS. 

301.2.3.6  FUNCTIONAL  PURPOSE: 

REQ  RISK  THE  OBJECTIVE  OF  THIS  PROCESS  IS  TO  ASSESS  THE  POTENTIAL 

VALIDATION  FUNCTIONAL  REQUIREMENT  RISKS  IDENTIFIED  THROUGH  COMPARATIVE  ANALYSIS  IN 
PROCESSES  301.2.3.2  THROUGH  301.2.3.5  AND  VALIDATE  WHEN  JUSTIFIED  THESE 
POTENTIAL  RISKS  AS  RISKS  INVOLVED  IN  SATISFYING  NEW 
SYSTEM/EQUIPMENT  FUNCTIONAL  REQUIREMENTS. 

301.2.3.6A1  DEVELOP  PURPOSE: 

RSK  VALID-  THIS  PROCEDURE  IS  DESIGNED  TO  ESTABLISH  CRITERIA  UPON 

ATION  CRIT  WHICH  TO  VALIDATE  THE  PREVIOUSLY  IDENTIFIED  POTENTIAL  NEW 

SYSTEM/EQUIPMENT  FUNCTIONAL  REQUIREMENTS  RISKS,  AS  RISKS  INVOLVED  IN 
SATISFYING  FUNCTIONAL  REQUIREMENTS , 

301.2.3.6A2  UNIQUE  PURPOSE: 

FUNCTIONAL  THIS  PROCESS  UTILIZES  THE  FUNCTIONAL  REQUIREMENT  WORKSHEET, 

RQMNTS  RSK  (ANNEX  C)  INCLUDING  THE  ASSESSMENTS  MADE  IN  PRIOR  PROCESSES,  AND  THE 
RISK  VALIDATION  CRITERIA  OF  PROCESS  301.2.3.6A1  TO  IDENTIFY  UNIQUE 
FUNCTIONAL  REQUIREMENT  RISKS. 

301.2.3.6A3  SUPP,  COST  PURPOSE: 

READINESS  THIS  PROCESS  UTILIZES  THE  FUNCTIONAL  REQUIREMENTS 

DRIVER  RSK  WORKSHEET,  (ANNEX  C)  INCLUDING  THE  .ASSESSMENTS  MADE  IN  PRIOR  PROCESSES, 
AND  THE  RISK  VALIDATION  CRITERIA  IN  PROCESS  301.2.6A1  TO  IDENTIFY 
SUPPORTABILITY,  COST  AND  READINESS  RISKS. 

301.2.3.6A4  OTHER  PURPOSE: 

IDENT  FUNC  THIS  PROCESS  UTILIZES  THE  FUNCTIONAL  REQUIREMENTS  WORKSHEET 

RQMNT  RISK  (ANNEX  C),  INCLUDING  THE  ASSESSMENTS  MADE  IN  PRIOR  PROCESSES,  AND  THE 
RISK  VALIDATION  CRITERIA  IN  PROCESS  301.2.3.5A1  TO  IDENTIFY  OTHER 
IDENTIFIABLE  FUNCTIONAL  REQUIREMENTS. 
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Name 


301.2. 


301.2. 


Label  Description 


3.SAS  VERT  PURPOSE: 

BASED  RISK  THIS  PROCESS  IS  DESIGNED  TO  ANALYZE  THE  POTENTIAL  FUNCTIONAL 

IDENT  REQUIREMENT  RISKS  NOT  PREVIOUSLY  IDENTIFIED  IN  PROCESSES  301.2.3.6A2 
THROUGH  301.2.3.6A4,  AS  FUNCTIONAL  RISKS,  AND  OR  TO  PROVIDE  A  DETAILED 
ANALYTICAL  PROCEDURE  FOR  USE  IN  IDENTIFYING  FUNCTIONAL  REQUIREMENT 
RISKS  WHERE  INDEPTH  ANALYSIS  IS  REQUIRED. 

3.6A6  FUNCTIONAL  PURPOSE: 

REQUIREMEN  USE  THIS  PROCESS  TO  ORGANIZE  AND  PRESENT  THE  FUNCTIONAL 

RISK  REQUIRfMENTS  RISKS  IDENTIFIED  IN  LSA  TASK  301.2.3. 
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Naae  Label  Description 


BCS/DTA  BASELINE  THIS  DATA  FLOW  CONTAINS  DATA  CONCERNING  THE  BASELINE  COMPARISON  SYSTEM 

COMPARATIVE  DEVELOPED  FOR  USE  IN  COMPARATIVE  ANALYSIS  AND  IN  IDENTIFYING 
SYSTEM  DATA  SUPPORTABILITY,  COST  AND  READINESS  DRIVERS. 

SOURCE:  LSA  TASS  203 

CONST/RSK/DTA  CONSTRUCTION  THIS  DATA  FLOW  CONTAINS  RISKS  IDENTIFIED  AS  BEING  ASSOCIATED  WITH 
RISK  DATA  SUPPORTABILITY  AND  SUPPORTABILITY  RELATED  DESI®  CONSTRAINTS. 

SOURCE:  LSA  TASK  202 

DES/RSK/DTA  DESI®  RISK  THIS  DATAFLOW  CONTAINS  RISKS  ASSOCIATED  WITH  ESTABLISHED  DESI® 

DATA  OBJECTIVES,  APPROACHES  NEEDED  TO  VERIFY  IMPROVEMENT  POTENTIAL,  AND  ANY 

COST  AND  SCHEDULE  IMPACTS. 

SOURCE:  LSA  TASK  204 

FUNC/RQMTS  FUNCTIONAL  THIS  DATAFLOW  CONTAINS  THOSE  ITEMS  IDENTIFIED  AS  NEW  SYSTEM/EQUIPMENT 

REQUIREMENTS  FUNCTIONAL  REQUIREMENTS 
DATA 

SOURCE:  TASK  301 

FUNC/RQMIS/DRIVERS  FUNCTIONAL  THESE  DATA  FLOWS  REPRESENT  THE  COMBINED  RESULTS  OF  LSA  TASK  301.2.1  AND 
REQUIREMENTS  301.2.2  AND  PERMITS  THE  ANALYST  TO  ACCESS  THE  COMBINED  FUNCTIONAL 
AND  DRIVERS  REQUIREMENTS,  UNIQUE  FUNCTIONAL  REQUIREMENTS,  AND  SUPPORTABILITY,  COST 
AND  READINESS  DRIVERS.  FOR  THE  NEW  SYSTEM  EQUIPMENT. 

FUNC/RQMTS/RISKS  FUNCTIONAL  THIS  DATA  FLOW  TRANSMITS  THE  RESULTS  OF  LSA  SUBTASKS  301.2.3  EFFORTS  TO 

REQUIREMENTS  THE  REQUIRING  AUTHORITY.  THE  RESULTS  OF  LSA  SUBTASK  301.2.3  ARE 
RISKS  TRANSMITTED  TO  THE  PROJECT  MANAGER  WHO  WILL  MAKE  A  DETERMINATION  AS  TO 

WHICH  OF  THE  IDENTIFIED  RISKS  NEED  TO  BE  SUBJECTED  TO  A  QUANTITATIVE 
DECISION  RISK  ANALYSIS  TECHNIQUE. 

INIT/ACT  INITIATE  PURPOSE:  DATA  IDENTIFYING  THE  NEED  FOR  ASSESSING  AN  ALTERNATIVE 

ACTION  SYSTEM/EQUIPMENT.  THIS  NEED  MAY  BE  BASED  ON  AN  EVALUATION  OF 

THE  EXISTING  MANPOWER/PERSONNEL  REQUIREMENTS  ON  THE  BASELINE 
SYSTIM/EQUIPMENT. 

THIS  DATA: 

1.  ESTABLISHES  MISSION  PROFILE. 

2.  IDENTIFIES  THE  RESOURCES  THAT  EXIST  AND/OR  MUST  BE 
DEVELOPED 

3.  ESTABLISH  PRIORITIES. 

SOURCE  OF  DATA:  PROGRAM  MANAGER 

POT/FUNC/RQMNTS/RISK  POTENTIAL  THESE  DATA  FLOW  REPRESENT  THE  COMBINED  FUNCTIONAL  REQUIREMENTS,  UNIQUE 
FUNCTIONAL  FUNCTIONAL  REQUIREMENT,  AND  SUPPORTABILITY,  COST  AND  READINESS  DRIVERS 
REQ  RISKS  (LSA  TASKS  301.2.1  AND  301.2.2)  WHICH  HAVE  BEEN  MANIPULATED  WITHIN  THIS 
SUBTASK.  THE  FLOWS  PRESENT  THE  ANALYST  THOSE  POTENTIAL  FUNCTIONAL 
REQUIREMENT  RISKS  REQUIRING  FURTHER  VALIDATION. 

RISK/CRIT  RISK  THIS  DATA  FLOW  PROVIDES  THE  ANALYST  CRITERIA  UPON  WHICH  TO  BASE 

CRITERIA  FUNCTIONAL  REQUIREMENTS  RISK  DETERMINATIONS.  THESE  CRITERIA  ARE 
DEVELOPED  IN  PROCESS  301.2.3.SA1 
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Naae 

SUPP/RSK/DTA 

UNIQUE/FUNC/DRIVERS 

VERT 


Label  Description 


SOPPORIAB' IT  THIS  DATA  FLOW  CONTAINS  RISKS  ASSOCIATED  WITH  SYSTEM  SUPP0RIABI1ITY 
RISK  DATA  DEVELOPED  IN  LSA  TASK  205. 

UNIQUE  •  THIS  DATA  FLOW  CONTAINS  UNIQUE  FUNCTIONAL  REQUIREMENTS,  SUPPORTABILITY 
FUNCTIONS  i  COST  AND  READINESS  DRIVERS  AS  IDENTIFIED  IN  PROCESS  301.2.2 
DRIVERS 

VENTURE  VERT  IS  A  NETWORK  ANALYSIS  TECHNIQUE  USED  FOR  PERFORMING  DECISION 
EVALUATION  RISK  ANALYSIS  FROM  A  VARIETY  OF  PROGRAM  ASPECTS.  THE  TOOL  MAKES  IT 
AND  REVIEW  POSSIBLE  TO  MODEL  SYSTfM  REQUIREMENTS  AND  ANALYZE  THE  OUTCOMES  UNDER 
TECHNIQUE  VARIOUS  COST,  SCHEDULE,  AND  MANPOWER  CONSTRAINTS. 
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Naae 


PM/ILSMT 


VERT 


Label  Description 


PM/ILSMT  THE  PROGRAM  MANAGER  OR  THOSE  ACTIVITIES,  AGENCIES,  OR  AUTHORITIES  THAI 
INITIATE  ARE  RESPONSIBLE  FOR  THE  INITITATION  OF  THE  REQUIREMENT  FOR  AN  ILS 
REQRMNT  ELEMENT  ASSESSMENT  DURING  A  DEVELOPMENT  PROGRAM  FOR  A  SYSTEM  AND/OR 
EQUIPMENT  IN  ACCORDANCE  WITH  AR  700-127.  THE  KEY  ACTION  (OUTPUT) 
REQUIRED  OF  THIS  EXTERNAL  ENTITY  IS  THE  DIRECTIVE,  AUTHORITY,  OR  OTHER 
DOCUMENTATION  THE  INITIATES  THE  REQUIREMENT  FOR  THE  APPLICATION  OF  THIS 
ILS  ASSESSMENT  TO  A  SPECIFIC  SYSTEM/EQUIPMENT  DEVELOPMENT  PROGRAM  AT  A 
SPECIFIED  POINT  IN  ITS  LIFE  CYCLE. 

VENTURE  A  COMPUTERIZED  ,  MATHEMATICALLY  ORIENTED  SIMULATION  NETWORKING 
EVALUATIO  TECHNIQUE  DESIGNED  TO  ASSESS  RISKS. 

S  REVIEW 
TECHNIQUE 
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ANNEX  C 

LSA  SUBTASK  301.2.3 

FUNCTIONAL  REQUIREMENTS  RISK  ANALYSIS 


ANNEX  C 

LSA  SUBTASK  301.2.3 
FUNCTIONAL  REQUIREMENTS  RISK  ANALYSIS 


PROCESS  301.2.3.1  Review  Functional  Requirement  and 

Supportability  Drivers 

PURPOSE: 

The  objective  of  this  process  is  to  review  the  results  of  LSA 
Subtask  301.2.1  and  301.2.2,  which  together  identified  and 
documented  the  new  and  Unique  Functional  Requirement  of  the  new 
system/equipment  which  were  due  to  new  design  technology, 
operational  concepts,  supportability,  cost  or  readiness  drivers. 

PROCEDURES : 

1.  Obtain  results  of  Subtask  301.2.1  and  301.2.2 

2 .  Match  and  record  the  functional  requirements  for  each 
alternative  system  with  the  supportability,  cost  and 
readiness  drivers,  and  unique  system/equipment  functional 
requirements . 

3 .  Match  the  unique  functional  requirements  and 
supportability,  cost  and  readiness  drivers  against  the 
appropriate  functional  requirements  listed  (Process 
301.2.3.1)  .  Identify  matches  between  unique  functions  or 
drivers  with  system/equipment  functional  requirements. 

NOTE:  In  all  but  the  most  exceptional  case,  each  of  these  unique 

functional  requirements  and  drivers  will  have  a  matching 
functional  requirement  identified.  A  detailed  review  of 
supporting  rationale  may  be  required  to  effect  a  match. 

4.  Should  a  positive  match  not  be  possible,  document  these 
unique  requirements /drivers  in  the  worksheet  below  the 
last  functional  requirement  listed  in  the  first  column. 

5.  In  the  last  column  of  the  Functional  Requirements  and 
Support  Driver  list  document  the  supporting  rationale, 
references,  source  data,  etc.  relating  to  the  unique 
functional  requirements  or  drivers . 
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FUNCTIONAL  REQUIREMENTS  AND  SUPPORT  DRIVER  LIST 

(LSA  SUBTASK  301.2.3.1) 


GENERIC  REMARKS  FORM 

(ALL  PROCESSES) 


END  ITEM  NAME: 
i  NOMENCLATURE : 

PART  NUMBER: 

1 

t 

t 

|  FUNCTIONAL  REQUIREMENT  OR  DRIVER: 

I 

j  RISK  DESCRIPTION  OR  REMARKS: 

|  (TEXT  DESCRIPTION) 


| 

i 


AREAS  IMPACTED  ( SUPPORTABILITY/COST/READINESS ) : 
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PROCESS  301.2.3.2  -  Functional  Requirements /BCS  Evaluation 


PURPOSE : 

To  evaluate  functional  requirements,  unique  functional 
requirements  and  supportability ,  cost  and  readiness  drivers 
previously  identified  against  the  Baseline  Comparison  System 
developed  in  LSA  Task  203  to  provide  historical  data  upon  which 
to  base  risk  determinations. 


PROCESS  301.2.3.2A1  -  Functional  Requirements /BCS  Review 
PURPOSE: 

Determine  through  review  of  LSA  Subtask  203.2.2,  the 
relationships  that  may  exist,  between  the  baseline  comparative 
system  and  the  functional  requirements  and  drivers  previously 
identified. 

PROCEDURES : 

1.  Obtain  LSA  Subtask  203.2.2  results  from  the  Program 
Manager's  Office. 

2.  Utilizing  Functional  Requirement /BCS  Evaluation  Worksheet 
and  the  data  developed  in  Processes  301.2.1  and  301.2.2, 
compare  listed  functional  requirements,  unique  functions 
and  support ability,  cost  and  readiness  drivers  (columns 
1  and  2)  with  the  historical  data  available  from  LSA 
Subtask  203.2.2. 

3 .  Determine  those  elements  of  the  BCS  data  which  directly 
influence  or  may  influence  the  functional  requirements  and 
drivers .  Record  these  influences  in  the  column  marked  BCS 
Review  of  the  Worksheet  against  the  functional  requirement 
or  driver  influenced. 

4.  Use  the  remarks  column  to  record  supporting  rationale, 
reference  data,  source  data,  etc. 


C-4 


FUNCTIONAL  REQUIREMENT/BCS  EVALUATION 
(PROCESS  301.2.3.2)  _ 


301.2.3. 2A2  -  Functional  Requirement 3 /Qualitative  Support ability 
Review 


PURPOSE: 

Review  the  qualitative  support ability  problems  identified  in 
LSA  Subtask  203.2.4  against  functional  requirements,  unique 
functions  and  supportability,  cost  and  readiness  drivers  to 
identify  historically  significant  impacts  upon  the  new 
system/ equipment . 

PROCEDURES : 

1.  Obtain  LSA  Subtask  203.2.4  results  from  the  Program 
Manager ' s  Office . 

2.  Determine  if  a  direct  relationship  exists  between  any  of 
the  qualitative  supportability  problems  identified  for 
comparative  systems  and  the  functional/drivers  of  the  new 
system/ equipment . 

3 .  Record  those  instances  where  a  relationship  is  apparent 
in  the  column  marked  Supportability/Review,  against  the 
appropriate  functional  requirement,  unique  requirement  or 
supportability,  cost  or  readiness  driver.  Use  the  remarks 
column  to  document  source  date,  references,  rationale, 
etc . 

302.2.3.2A3  -  Functional  Recruirement3/BCS  Driver  Review 
PURPOSE: 

The  objective  of  this  process  is  to  compare  the  functional 
requirements  for  the  new  system/equipment  with  the  historical 
supportability,  cost  and  readiness  driver  data  contain  in  LSA 
Subtasks  203.2.5  and  203.2.6  and  determine  potential  program 
risks . 


PROCEDURES : 

1.  Obtain  the  output  of  LSA  Subtasks  203.2.5  and  203.2.6. 

2.  Review  the  supportability,  cost  and  readiness  drivers  and 
historically  significant  data  from  LSA  Subtask  203.2.5. 
Review  the  relationship  of  those  drivers  with  the  drivers 
determined  in  LSA  Subtask  203.2.6. 
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3 .  As  a  result  of  this  review,  compare  the  resulting  data 
with  the  information  generated  in  Process  301.2.7.1  (Since 
LSA  Subtask  203.2.6,  "Identification  of  Supportability , 
Cost,  and  Readiness  Drivers",  is  a  source  of  data  for  LSA 
Subtask  301.2.2,  "New  Equipment  Unique  Functional 
Requirements",  much  of  the  supportability,  cost  and 
readiness  driver  information  should  already  be  recorded.) 

4.  Record  results  of  the  above  comparative  analysis  in  column 
marked  Driver  Review  of  the  Worksheet.  The  remarks  column 
will  be  used  to  record  appropriate  source  data, 
references,  rationale,  etc. 


PROCESS  301.2. 3. 2A4  -  Functional  Requirements /Risk  and 

Assumption  Review 

PURPOSE : 

The  objective  of  this  process  is  to  determine  if  the  risks 
and  assumptions  associated  with  the  use  of  comparative  systems 
(LSA  Subtask  203.2.8)  influence  the  functional  requirements, 
unique  requirements  and  supportability ,  cost  and  readiness 
drivers  for  new  system/equipment. 

PROCEDURES : 

1.  Obtain  the  results  of  LSA  Subtask  203.2.8. 

2 .  Review  these  risks  and  assumptions  and  supporting 
rationale.  Through  comparative  analysis  determine  if  these 
comparative  system  risks  and  assumptions  are  analogous  or 
similar  to  the  functional  requirements,  unique  functions 
and  supportability,  cost  and  readiness  drivers . 

3.  When  a  functional  requirement  or  driver  is  influenced  by 
a  comparative  system  risk  or  assumption,  that  influence 
will  be  recorded  in  the  column  marked  Risk  and  Assumption 
Review.  Supporting  rationale,  references,  etc.  will  be 
recorded  in  the  remarks  column. 
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PROCESS  301.2.3.2A5  -  Functional  Requirements /BCS  Validation 
PURPOSE: 


This  process  assesses  the  results  of  the  preceding  reviews  of 
functional  requirements,  unique  requirements  and  suppdrtability, 
cost  and  readiness  driver  review  with  the  Baseline  Comparison 
System.  As  a  result,  potential  functional  risks  are  identified. 

PROCEDURES : 

1.  Compare  the  four  preceding  processes  (LSA  Subtask3 
301.2.3.3A1  through  301.2.3.3A4)  results  as  listed  in 
the  respective  Worksheets  with  those  functional 
requirements/drivers  impacted. 

2.  Determine  if  these  comparisons  warrant  a  designation  of 
a  functional  requirement /driver  as  a  potential  functional 
requirements  risk.  If  such  designation  is  made,  so 
indicate  it  in  the  column  marked  Potential  Functional 
Requirements  Risks . 


PROCESS  301.2.3.3  -  Functional  Requirements /Constraint  Ri3k 

Assessment 

PURPOSE: 

The  objective  of  this  process  is  to  assess  relationships 
between  the  functional  requirements,  unique  functional 
requirements  and  support ability ,  cost  and  readiness  drivers  and 
risks  associated  with  3upportability  constraints. 

PROCEDURES : 

1.  Obtain  the  results  of  LSA  Subtask  202.2.4  which  identified 
risks  associated  with  supportability  and  supportability 
related  design  constraints. 

2.  Utilizing  the  results  of  LSA  Subtask  202.2.4,  "Mission 
Hardware,  Software  and  Support  System  Standardization 
Risks",  document  the  following  on  the  Support  Constraint 
Risk  Identification  Worksheet. 

a.  If  the  functional  requirements  and  support  drivers  are 
in  conflict  with  standardization  requirements  of  the 
new  system  due  to  the  need  to  develop  new  support 
items . 
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SUPPORT  CONSTRAINT  RISK  IDENTIFICATION 
(PROCESS  301.2.3.3) 


FUNCTIONAL  REQUIREMENT /DESIGN  OBJECTIVE  RISK  IDENTIFICATION 

(PROCESS  301.2.3.4) 


b.  Development  of  new  support  items  are  in  conflict  with 
existing  DOD/Army  Support  Policies  such  as  requiring 
the  use  of  standard  test  equipment  or  software 
languages . 

c.  Risks  associated  with  developing  new  items  of  support. 

d.  If  the  functional  requirements  and  support  drivers 
require  existing  logistic  resources;  have  shortages 
been  identified  or  are  those  items  being  eliminated 
from  the  Army  inventory. 

e.  Instances  were  the  new  system/ equipment  is  going  to 
compete  for  existing  logistic  resources. 

3.  If,  as  a  result  of  this  assessment,  constraint  risks  are 
determined  to  impact  functional  requirements  or  drivers 
the  column  marked  Support  Constraint  Risks  will  be  used 
to  indicate  those  relationships .  The  remarks  column  will 
be  used  to  record  rationale,  references,  source  data,  etc. 


PROCESS  301.2.3.4  -  Functional  Requirements /Design  Objective 

Risk  Assessment 

PURPOSE: 

The  purpose  of  this  process  is  to  determine  the  relationships 
that  exist  between  risks  associated  with  design  objectives,  as 
identified  in  LSA  Subtask  204,  and  functional  requirements, 
unique  functional  requirements  and  supportability ,  cost  and 
readiness  drivers . 


PROCEDURES : 

1.  Obtain  the  risks  identified  in  LSA  Subtask  204.2.3  as 
being  associated  with  design  objectives. 

2.  Based  on  the  results  of  LSA  Subtask  204.2.3, 
"Technological  Opportunity  Risks",  document  the  following 
potential  risks: 

a.  New  design  requirements  resulting  from  functional 
requirements  and  supportability  goals  that  increase 
logistic  resource  requirements,  support  cost  and/or 
have  a  negative  impact  on  system  readiness  (e.g., 
adding  BIT  detection  circuitry  that  reduces  the 
reliability  of  a  circuit  board) . 
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b.  Technological  advances  driven  by  the  new  system's 
functional  requirements  or  supportability  goals  that 
require  new  logistic  resources  and  therefore  will 
impact  the  cost  and  schedule. 

c.  The  impact  of  not  implementing  a  technological 
opportunities  on  the  logistics  resource  requirement, 
supportability  costs,  and  system  readiness. 

3.  Using  the  Functional  Requirement/Design  Object 
Identification  Worksheet,  record  those  instances  where 
design  objective  risks  directly  impact  a  functional 
requirement /'driver  in  the  column  marked  Design  Objective 
Risks.  The  remarks  column  will  be  used  to  record 
rationale,  supporting  data,  references,  etc. 


PROCESS  301.2.3.5  -  Functional  Requirements /Support ability 

Risk  Assessment 

PURPOSE : 

The  objectives  of  this  process  i3  to  assess  the  relationship 
of  supportability  risks  associated  with  new  technology  and 
supportability,  cost  and  readiness  objectives  risks  as 
identified  in  LSA  Subtask  205.2.2,  and  functional  requirements, 
unique  functional  requirements  and  support ability,  cost  and 
readiness  drivers . 

PROCEDURES : 

1.  Obtain  the  results  of  LSA  Subtask  205.2.2. 

2.  Using  the  results  of  LSA  Subtask  205.2.2,  "Supportability 
and  Supportability  Related  Design  Factor  Risks",  document 
the  following  impacts: 

a.  Based  on  the  functional  requirements  and  unique 
supportability  drivers  will  the  identified  viable 
support  concepts  pose  any  problems  in  meeting 
supportability,  cost,  and  readiness  objectives. 
Consider  how  the  viable  support  concepts  utilize 
logistic  support  resources  and  the  degree  of  operation 
and  support  costs  which  will  be  incurred  during  the 
system  life  cycle. 
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DESIGN  OBJECTIVE  RISK 
(PROCESS  301.2.3.5) 


c-n 


b.  Identify  new  technology  that  is  proprietary  or  source 
controlled  but  is  required  because  of  new  system 
functional  requirements  and/or  unique  support  drivers. 
Identify  any  impact  this  will  have  on  supportability, 
cost,  or  readiness. 

c.  Identify  any  system  function  or  unique  support  drivers 
that  will  be  impacted  from  items  outside  (GFE,  ALDT) 
the  control  of  the  performing  agency  which  have  an 
impact  system  readiness. 

3.  Assess  the  relationship  of  these  supportability  design  and 
technological  risks  with  the  identified  functional 
requirements /drivers  recorded  in  Design  Objective  Risk 
Worksheet.  Determine  through  this  assessment  if  these 
supportability  risks  impact  the  functions/drivers .  Record 
those  supportability  risks  impacts  in  the  column  marked 
Support  Design  Risks  of  the  Functional  Requirements 
Worksheet.  Use  the  remarks  column  for  recording 
supporting  ratiorale,  remarks,  source  data,  etc. 


PROCESS  30 1.2. 3. 6  -  Functional  Requirement  Risk  Validation 
PURPOSE: 

The  objective  of  this  process  is  to  assess  the  potential 
functional  requirement  risks  identified  through  comparative 
analysis  in  processes  301.2.3.3  through  301.2.3.6  and  validate, 
when  justified,  these  potential  risks  as  risks  involved  in 
satisfying  new  system/  equipment  functional  requirements. 


PROCESS  301.2.3.6A1  -  Develop  Risk  Validation  Criteria 
PURPOSE : 

This  procedure  is  designed  to  establish  criteria  upon  which 
to  validate  the  previously  identified  potential  risks  associated 
with  the  new  system/equipment  functional  requirements. 

PROCEDURES : 

On  the  Risk  Validation  Criteria  Selection  Worksheet  identify 
the  Validation  Criteria  based  on  the  following  factors . 

1.  Identify  a  functional  requirement  as  a  de  facto  ri3k  if 
it  has  been,  is  currently  or  will  be: 
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a.  Designated  a  unique  functional  requirement  or  is  so 

influenced  by  a  unique  functional  requirement  that  it 
actually  is  or  becomes  a  unique  functional 

requirement . 

b.  Designated  a  supportability,  cost  or  readiness  driver 
or  is  so  influenced  by  a  supportability  cost  or 
readiness  driver  that  it  actually  is  or  becomes  such 
a  driver. 

2.  Other  functional  requirements,  which  were  classified  as 
potential  risks,  may  qualify  under  the  weight  of 
comparative  data  available  or  may  require  further  and  more 
detailed  analysis. 

a.  Should  a  functional  requirement  be  influenced  by  a 
number  of  assessment  criteria  (Processes  301.2.3.3 
through  301.2.3.6  above)  the  weight  of  the  data  alone 
may  warrant  a  designation  of  that  functional 
requirement  as  a  risk. 

b.  Likewise,  should  the  weight  of  data  indicate  that 

further  detailed  analysis  is  necessary  to  identify  a 
potential  functional  requirement  as  a  risk,  a  more 

detailed  analytical  procedure  must  be  selected. 

(Other  potential  functional  risks  may  be  evaluated  by 
this  method  should  the  analyst  so  choose.) 

c.  Of  the  analytical  options  available  to  assess 

potential  risks  as  identifiable  functional  requirement 
risks  is  the  Venture  Evaluation  and  Review  Technique 
(VERT) .  This  simulation-based  risk  analysis  tool  has 
proven  successful  in  acquisition  life-cycle 
evaluations  for  several  Army  programs  and  is  readily 
adaptable  to  various  new  systems/equipment  logistic 
analysis.  Other  equally  appropriate  computer  based 
options  exist  for  the  analyst. 

PROCESS  3Q1.2.3.6A2  -  Unique  Functional  Requirements  Risks 

PURPOSE: 

This  process  utilizes  the  unique  Functional  Requirements  Risk 
Worksheet,  including  the  assessments  made  in  prior  processes, 
and  the  risk  validation  criteria  from  Process  301.2.3. 6A1  to 
identify  Unique  Functional  requirement  risks. 
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RISK  VALIDATION  CRITERIA  SELECTION 
(PROCESS  301.2.3. 6A1) 
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UNIQUE  FUNCTIONAL  REQUIREMENTS  RISKS 

(301.2.3.6A 2) 


PROCEDURES : 


1 .  Obtain  the  results  of  Process  301.2.3.1  through  301.2.3.6. 

2.  Obtain  the  Unique  Risk  Validation  Criteria  developed  in 
Process  301.2.3. 6A1. 

3.  Analyze  each  functional  requirements  against  the  BCS  and 
Risk  data  to  determine  those  risks  that  are  unique 
functions  based  on  the  Risk  Validation  Criteria 
(301.2.3. 6A1) . 

4  .  Indicate  in  the  column  marked  Unique  Function  Risks  of  the 
Worksheet  by  checking  those  functional  requirement  lines 
that  are  now  classified  as  unique  risks.  Use  the  remarks 
to  reference  any  related  information  or  data. 


PROCESS  301.2.3. 6A3  -  Support ability.  Cost  and  Readiness  Driver 

Risks 

PURPOSE: 

This  process  utilizes  the  Supportability ,  Cost,  Readiness 
Driver  Risk  Worksheet,  including  the  assessments  made  in  prior 
processes,  and  the  risk  validation  criteria  in  Process 
301.2.3. 6A1  to  identify  Supportability,  Cost  and  Readiness 
risks . 

PROCEDURES : 

1.  Follow  the  procedures  outlined  for  Process  301.2.3. 6A2 
above  except  that  supportability,  cost  and  readiness 
drivers  are  analyzed  in  this  process.  Again,  the  criteria 
established  in  Process  301.2.3.6A1  will  govern  risk 
determination . 

2.  The  column  marked  Support,  Cost,  and  Readiness  Driver 
Risks  of  the  Worksheet  will  be  used  to  document 
supportability,  cost  and  readiness  driver  risks.  The  last 
column  will  be  used  for  remarks . 

PROCESS  301.2.3.6A4  -  Other  Identifiable  Functional  Requirement 

Risks 

Thi3  process  utilizes  the  Other  Identifiable  Functional 
Requirement  Risk  Worksheet,  including  the  assessments  made  in 
p 'ior  processes,  and  the  risk  validation  criteria  in  Process 
3.1.2. 3. 6A1  to  identify  Other  Functional  Requirements. 
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SUPPORTABILITY,  COST,  READINESS  DRIVER  RISKS 

(PROCESS  301.2.3. 6A3) 


w 
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OTHER  IDENTIFIABLE  FUNCTIONAL  REQUIREMENTS  RISKS 

(PROCESS  301.2.3. 6A4) 


PROCEDURES : 


1.  Follow  the  procedures  outlined  for  Process  301.2.3. 6A2 
above  except  that  those  functional  requirements  influenced 
by  the  weight  of  assessed  data  as  described  in  criteria 
established  in  Process  301.2.3. 6A1  will  govern  a 
determination  of  risk. 

2.  Use  the  column  marked  Identif iable  Functional  Requirements 
Risks  of  the  Worksheet  to  record  these  "Other"  risks. 
Any  comments  or  reference  will  be  placed  in  the  remarks 
column . 

PROCESS  301.2.3. 6A5  -  VERT  Based  Functional  Requirements  Risk 

Identification 


PURPOSE: 

This  process  is  designed  to  analyze  the  potential  functional 
requirement  risks  not  previously  identified  in  Processes 
301.2.3. 6A2  through  301.2.3. 6A4,  as  functional  risks,  and/or  to 
provide  a  detailed  analytical  procedure  for  use  in  identifying 
functional  requirement  risks  where  in-depth  analysis  is 
required . 

PROCEDURES : 

1.  Obtain  the  results  of  Processes  301.2.3.1  through 
301.2.3. 6A4 . 

2 .  Determine  which  potential  functional  requirements  remain 
that  require  detailed  analysis . 

3.  Select  an  analytical  tool  such  as  the  Venture  Evaluation 
and  Review  Technique  (VERT) ,  a  simulation-based  risk 
analysis  model,  to  identify  remaining  functional 
requirement  risks . 

4 .  Record  the  results  of  VERT  analysis  on  the  Risk  Analysis 
Worksheet  if  a  determination  is  made  that  an  analyzed 
functional  requirement  does  in  fact  represent  a  functional 
requirement  risk. 
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VERT  RISK  ANALYSIS 
(PROCESS  301.2.3.6A5) 
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PROCESS  301.2.3. 6A6  -  Functional  Requirement  Risk  Consolidation 


PURPOSE: 

Use  this  process  to  organize  and  present  the  functional 
requirements  risks  identified  in  LSA  Task  301.2.3. 

PROCEDURES : 

1.  Obtain  all  identified  risks  from  previous  processes. 

2.  Consolidate  this  data  for  inclusion  on  the  Functional 
Requirements  Risk  Consolidation  Worksheet  the  following: 

a.  Unique  Functional  Requirement  Risks. 

b.  Supportability ,  Cost  and  Readiness  Driver  Risks. 

c.  Other  Identif iable  Functional  Requirements  Risks. 

d.  VERT  Functional  Requirements  Based  Risk 
Identification . 

3 .  Provide  the  Functional  Requirement  Risk  Consolidation 
Worksheet  to  the  new  system/equipment  program  manager  or 
the  Integrated  Logistics  Support  Management  Team  (ILSMT) 
as  directed. 
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FUNCTIONAL  REQUIREMENT  RISK  CONSOLIDATION 
(PROCESS  301.2.3. 6A6) 


VERT  APPLICATION  METHODOLOGY 


BACKGROUND: 

Venture  Evaluation  and  Review  Technique  (VERT)  was  developed  a3 
a  network  analysis  technique  to  facilitate  management  decision 
making.  It  allows  a  systematic  planning  and  control  of  programs 
and  enables  managers  to  find  solutions  to  real  life  managerial 
problems . 

The  terms  of  the  APJ  contract  require  the  provision  of  batch 
files  for  each  of  the  VERT  networks  associated  with  the  various 
Data  Flow  Diagrams  in  the  APJ  966  projects. 

APJ  has  been  successful  in  adopting  a  method  for  the  creation  of 
these  networks  using  the  existing  EXCELERATOR  software  package  and 
establishing  a  naming  convention  compatible  with  that  used  in  the 
Data  Flow  Diagrams.  To  do  this  APJ  has  made  use  of  the  PC  model 
of  VERT.  A  Structured  Analysis  project  was  used  for  this  purpose. 
The  prototype  VERT  network  structure  was  made  for  one  top  level  and 
one  lower  level  data  flow  diagram. 

The  PC  model  of  VERT  has  certain  limitations  built  into  it.  To 
overcome  some  of  these  limitations,  certain  conventions  were  used 
to  create  the  input  files.  To  maintain  full  generality  a  set  of 
"dummy "  default  values  were  established .  The  model  allows  the  user 
to  alter  the  default  values  of  time,  cost,  and  performance  to 
satisfy  their  specific  requirements. 

METHODOLOGY: 

The  basic  symbols  used  to  structure  the  network  are  : 

(i)  SQUARES  -  to  indicate  NODES.  These  are  decision  points 
in  the  project,  or  points  beyond  which  the  project  cannot 
proceed  unless  certain  criteria  are  met.  There  are  two  types 
of  nodes,  one  which  supports  input  operations  and,  the 
second  type  which  supports  output  operations. 

(ii)  LINES  -  to  indicate  ARCS  which  are  activities  that  have 
time,  cost,  and  performance  criteria  associated  with  them. 

In  practice,  however,  both  the  arcs  and  nodes  are  similar,  in 
that  both  have  time,  cost,  and  performance  criteria  associated  with 
them.  The  arcs  have  a  primary  and  a  cumulative  set  of  time,  cost, 
and  performance  criteria  whereas  the  nodes  have  only  a  single 
cumulative  set. 
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(iii)  NAMING  CONVENTIONS  -  Efforts  have  been  made  to  keep 
the  naming  convention  as  compatible  as  possible  to 
the  Data  Flow  Diagrams.  The  naming  convention  used 
is  displayed  below. 

NODES  -  All  nodes  are  prefixed  with  the  letter  N.  The 
individual  Nodes  are  identified  by  a  number  and  a  letter. 
The  number  refers  to  the  number  of  the  node  within  the 
diagram  and  the  letter  refers  to  the  diagram  number  in  the 
project.  In  the  event  that  a  node  has  been  referenced  in  an 
earlier  diagram  they  also  carry  the  number  of  the  node  in 
the  earlier  diagram  as  a  prefix  to  the  individual  node 
number . 

N2.4A 

N  -  All  nodes  are  prefixed  with  the  letter  N 

2  -  Gives  the  number  of  the  node  it  relates  to  in  a 

higher  level  diagram  or  an  earlier  data  flow  diagram 
within  the  project.  In  thi3  case  it  refers  to  node 
N2  of  the  top  level  diagram. 

4  -  Gives  the  number  of  the  node  in  the  present 

data  flow  diagram. 

A  -  The  nodes  in  each  subsequent  explosion  are 

allotted  an  alphabetical  3uffix  indicating  the 
number  of  the  explosion  diagram  in  the 
particular  project.  In  this  case,  it  is  the 
first  lower  level  diagram  within  the  project. 

ARCS  -  All  arcs  are  prefixed  with  either  the  letter  C  or  E. 
The  individual  Arcs  are  identified  by  two  numbers.  The  first 
number  refers  to  the  number  of  the  arc  within  the  diagram 
and  the  second  number  refers  to  the  number  of  the  diagram 
within  the  project.  In  the  event  that  an  arc  has  been 
referenced  in  an  earlier  diagram  they  also  carry  the  number 
of  the  arc  in  the  earlier  diagram  as  a  prefix  to  the 
individual  arc  number.  The  arcs  which  are  identified  by  the 
letter  B  have  direct  reference  to  a  process  in  the 
corresponding  data  flow  diagram  and  as  such  are  named  the 
3ame  as  the  process  itself. 

C3.3.8.4  E12.1A2 

C  -  All  arcs  are  prefixed  with  the  letter  C.  In 

some  cases,  however,  arcs  carry  a  prefix  of  B. 
These  particular  arcs  correspond  to  a  process 
within  the  data  flow  diagram  and  are  thus 
named  the  same  as  the  process  itself. 


D-2 


3.3 


Gives  the  number  of  the  arc  it  relates  to  in  a 
higher  level  diagram  or  an  earlier  data  flow  diagram 
within  the  project.  In  this  case,  it  refers  to  arc 
number  3  in  lower  level  diagram  #3  within  the 
project . 

8.4  -  Indicates  that  this  particular  arc  is  the  #8  arc 

in  the  #4  lower  level  diagram  of  the  project. 

BATCH  FILES 

INPUT  FILES  -  The  input  file  names  are  given  the 

extension  *.IN. 

OUTPUT  FILES  -  The  simulation  output  files  are  given 

the  extension  *.0U. 

PRINT  FILES  -  The  print  files  have  been  given  the 

extension  *.PR. 

(This  would  allow  subsequent  updates  of  the  input  files  to 
be  numbered  as  INI . . . , 0U1 . . . , PR1 . . .  etc . ) 

DEFAULT  SETTINGS: 

Control  Record: 

(i)  The  output  option  selected  is  "0"  which  provides  a 
detailed  listing,  and  high  level  of  summary 
information . 

(ii)  The  input  record  listing  option  selected  is  "0" 
which  prints  all  input  records. 

(iii)  The  composite  terminal  node  output  option 

selected  is  "16”  which  assumes  family  mode 
and  intrafamily  transfer  of  histogram  data. 

(iv)  The  number  of  iterations  used  are  "10"  in 

the  demonstration  model  to  facilitate  operation 
in  the  debug  mode  if  required. 

(v)  The  composite  node  name  and  the  network  name  are 
left  as  blanks. 

(vi)  in  the  run  identification  the  name  of  the 
corresponding  Data  Flow  Diagram  is  used  as 
identification  for  the  network  description. 
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Arc  Records : 

(i)  For  each  of  the  arcs  the  following  records  are 
provided : 

(a)  Master  Arc  Record 

(b)  Time  Distribution  Satellite 

(c)  Cost  Distribution  Satellite 

(d)  Performance  Distribution  Satellite 

(ii)  The  Distribution  Satellite  Records  are  created  to 
provide  a  uniform  statistical  distribution. 

(iii)  The  default  values  used  for  the  minimum  and 
maximum  in  each  criteria  are: 

TIME  10.0 

COST  10.0 

PERFORMANCE  10.0 

Node  Records : 

(i)  Input  Logic  -  The  input  logic  for  the  nodes  are  either 

"INITIAL"  or  "AND". 

(ii)  Output  Logic  -  The  output  logic  has  been  defaulted  to 

"AND"  or  " TERMINAL " . 

(iii)  The  output  option  indicator  and  the  storage  option 
indicator  are  defaulted  to  read  "O" . 

(iv)  The  node  description  has  also  been  left  blank. 

(It  is  again  noted  that  the  user  cam  change  the  default 
.  values  to  desired  values  as  identified  by  the  particular 
requirement  and  applications . ) 

DOCUMENTATION: 

With  every  project  report  APJ  will  be  providing  the 
following  documents  relating  to  the  VERT: 

(i)  A  VERT  network  diagram  corresponding  to  a  particular 
data  flow  diagram. 

(ii)  A  print  out  of  the  VERT  network  inputs  for  the 
particular  data  flow  diagrams . 

(iii)  A  floppy  disc  containing  sample  input,  print,  and 
the  simulation  output  files  for  the  default  VERT 
network . 
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ANNEX  E 

STRUCTURED  SYSTEMS  ANALYSIS 
Fundamentals 


NOTE:  Our  presentation  of  Structured  Analysis  Fundamentals  with 
the  associated  figures  is  reproduced  verbatim  in  each 
report. 
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Structured  Systems  Analysis  (SSA)  ha3  recently  become  an 
industry  standard  for  generating  Data  Flow  Diagrams  (replacing 
"logic  diagrams"  or  "flow  charts")  to  aid  in  coordinating  the 
functions  to  be  performed  by  a  computer  program  and  its 
associated  Inputs /Outputs  (I/O) .  During  the  SSA,  each  set  of 
"flow  charts"  can  be  checked  by  the  potential  user  to  assure 
that  there  is  complete  agreement  on  what  is  to  be  done  by  the 
program,  and  how  it  is  to  be  accomplished.  It  also  provides 
considerable  flexibility  for  updating  or  changing  the  program. 

Six  basic  elements  (see  Figure  1)  are  used  in  SSA: 


1 . 

Process  (PRC) 

2. 

Data 

Flow  (DAF) 

3  . 

Data 

Store  (DAS) 

4  . 

External  Entity 

(EXT) 

5  . 

Data 

Flow  Diagram  (DFD) 

6. 

Data 

Dictionary 

(DCT) 

PROCESS  (Represented  by  a  Circle) : 

A  function  or  operation  to  be  performed  which  can  be 
explained  by  a  set  of  instructions  representing  a  single  task, 
e.g.,  "calculate  interest  on  a  loan",  "prepare  a  draft 
report".  If  the  Process  description  is  too  complex  to 
describe  in  a  few  steps,  it  may  be  necessary  to  develop  a 
lower  level  description  (see  below) . 

DATA  FLOW  (Lines  interconnecting  Processes  or  I/Os) : 

Each  function  or  Process  cannot  be  a  stand-alone  in  a 
complex  network .  To  have  any  meaning  in  a  program,  each 
process  must  be  initiated  by  a  previous  action  and/or  provided 
information  on  which  to  act.  Furthermore,  a  Process  must 
result  in  an  output  which  is  the  input  to  the  next  logical 
Process.  These  inputs,  outputs,  or  initiating  actions  are 
identified  as  Data  Flows,  and  are  represented  by  the  Data  Flow 
lines  indicating  its  point  of  origin  and  the  process  to  which 
it  provides  data. 
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DATA  STORE  (Represented  by  two  parallel  lines) : 

Although  some  Processes  generate  data  used  as  input  to 
a  succeeding  Process,  there  i3  often  a  need  to  "gather  or 
collect"  information  from  files  in  which  it  is  stored.  This 
information  may  come  from  an  external  source  (such  as  a 
MIL-STD,  Army  regulation,  historical  experience  files,  etc.), 
or  an  internal  source  or  file  in  which  data  is  temporarily 
stored  for  use  by  succeeding  processes.  These  Data  Stores  can 
be  visualized  as  a  "file  cabinet",  in  which  the  data  are 
stored  for  later  retrieval) . 

EXTERNAL  ENTITY  (Represented  by  a  Rectangle) : 

Each  program  or  logical  process  must  have  an  initiating 
action,  a  "point"  of  disposition  of  the  results,  and  possible 
input  guidance  or  instructions.  Each  of  these  have 
authorities,  functions,  or  applications  which  are  independent 
of  the  program  Process  (although  required  by  the  program 
Process) .  Thus,  these  activities,  agencies,  or  facilities  are 
considered  "External  Entities"  to  the  program. 

DATA  FLOW  DIAGRAM: 

The  general  arrangement  of  the  above  can  be  readily  seen. 
First,  the  circle  or  Process  describes  what  has  to  be  done; 
the  interconnecting  lines  represent  the  Data  Flows,  together 
with  the  specific  description  of  all  I/Os.  The  Data  Stores 
identify  the  source  and/or  file  designation  of  a  data  base, 
and  the  External  Entities  represent  those  activities  remote 
from  the  Process,  which  are  the  source  of  guidance  or  the 
recipients  of  the  program.  This  combination  of  Processes, 
Data  Flows,  Data  Stores,  and  External  Entities  constitutes  a 
"Data  Flow  Diagram" .  The  unique  feature  of  the  Data  Flow 
Diagram  (DFD)  is  that  each  process  can  be  considered 
independently,  permitting  a  change  to  be  made  in  one  Process 
without  a  major  change  in  the  overall  program. 

DATA  DICTIONARY: 

The  Data  Dictionary  consists  of  a  complete  description 
of  each  of  the  basic  elements.  For  the  Process,  it  contains 
a  step-by-step  description  of  what  has  to  be  performed.  The 
description  of  the  Data  Flow  identifies  the  nomenclature  of 
the  data,  a  detailed  description  of  its  content,  and  its 
source.  The  Data  Stores  and  External  Entities  are  described, 
including  possible  location. 
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The  Data  Dictionary  {a  living  document)  begins  with  a 
description  of  the  first  Process  and  is  continually  built-up 
as  the  Data  Flow  Diagrams  are  expanded,  detailed,  and 
eventually  completed. 

APPROACH  TO  PERFORMING  STRUCTURED  SYSTEM  ANALYSIS: 

The  best  approach  to  Structured  Systems  Analysis  is  to 
assume  that  the  program  consists  of  a  series  of  processes, 
each  of  which  are  to  be  assigned  to  an  inexperienced  analyst. 
Each  analyst  is  to  be  walked  through  the  assigned  process  of 
the  Program,  explaining  step-bywhfctep  functions  have  to  be 
performed  or  what  actions  have  to  be  taken  to  accomplish  the 
process .  The  analyst  is  also  informed  where  the  information 
is  coming  from  (input  Data  Flow) ,  what  is  to  be  generated  by 
each  process  (output  Data  Flow) ,  where  the  data  base  may  to 
be  found  (Data  Stores) ,  and  who  to  contact  for  guidance 
(External  Entities) . 

The  best  way  to  initiate  a  SSA  is  to  set  down  the  point 
of  origin  of  a  program,  its  final  goal(s),  and  the 
intermediate  functions  or  actions  needed  to  get  from  beginning 
to  goal.  Each  step  should  be  considered  as  a  Process  -  some 
may  be  sequential  and  others  parallel.  Then,  the  steps  needed 
to  accomplish  the  Process  should  be  described.  If  the 
description  is  complex  and  needs  intermediate  steps,  the 
Process  is  then  a  candidate  for  an  "explosion".  That  is,  the 
top  (or  upper)  level  Process  is  considered  as  a  "project"  and 
its  own  Data  Flow  Diagram  is  prepared. 

When  writing  the  step-by-step  procedures  in  the  Process, 
certain  elements  of  data  (or  information)  must  be  made 
available  for  the  procedure.  Each  element  of  data  is 
considered  as  an  input  Data  Flow,  which  is  identified  and 
described.  The  product  (or  result)  of  a  Process  is  an  output 
Data  Flow  element . 

Each  Data  Flow  to  the  Process  must  originate  from: 

1.  am  earlier  Process 

2.  a  Data  Store  (or  file) 

3.  an  External  Entity. 

These  sources  are  also  identified,  described  and  put  into 
the  Data  Dictionary.  As  soon  as  the  last  portion  of  the  Data 
Flow  Diagram  has  been  described,  the  SSA  is  complete. 
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The  structured  Analysis  phase  is  followed  by  Structured 
Design,  then  by  programming  and  finally  software  test  and 
validation.  The  organization  of  Structured  Analysis  and  its 
relationship  to  Structured  System  Design  is  3hown  on  below  on 
Figure  2 . 


E-4 


Structured 

Analysis 


Interface 
- *— 


Structured 

Systems 

Design 


REV1EW/CRITIQUE/ACCEPTANCE  OF  DFD 


Figure  1.  Structured  Analysis  &  Structured 
Systems  Design  Organization 
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REPRESENTS  A  PROCESS,  FUNCTION 
OR  ACTION 


REPRESENTS  A  DATA  STORE  OR  A 
DATA  FILE  -  OFTEN  IDENTIFIED  AS 
A  REPOSITORY  OF  INFORMATION  OF 
A  SPECIFIC  TYPE 


REPRESENTS  A  DATA  ELEMENT 
FLOW  INDICATING  OUTPUT  FROM 
ONE  PROCESS  AND  INPUT  TO 
ANOTHER  PROCESS 


REPRESENTS  AN  EXTERNAL 
ENTITY  -  AN  ACTIVITY  NOT  A 
PART  OF  THE  SYSTEM/PROCESS 
BEING  MODELED. 


Figure  2.  Standard.  DFD  Symbol  Definitions 
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